Think my biggest concern is the actual and intended views are filtered too. I fully agree a filtered compliance has tons of value, but that doesn't mean the intended/actual should be filtered as well. (IMHO). I think the below should happen.

1. Actual should show as if the old "search" is being used. "interface" is the root/parent and it shows the entire interface section with all config.
2. Intended ^^ same as above
3. The actual compliance result should be filtered down to the hier_config rule definition.

I think filtered is the whole point TBH. Compliance rules as they stand today are currently filtered if you think about it from a certain point of view - you’re matching on the parent command rather than displaying the whole intended in one screen. For example my intended config can have loads of lines which don’t have a compliance rule set and the app is happy with all the rules green.

I think filtered is the whole point TBH. Compliance rules as they stand today are currently filtered if you think about it from a certain point of view - you’re matching on the parent command rather than displaying the whole intended in one screen. For example my intended config can have loads of lines which don’t have a compliance rule set and the app is happy with all the rules green.

I understand your viewpoint; however, it shifts many other users use cases. Many people use the other config plan types for example (intended) which pulls from the compliance result. This now means its a filtered intended config-set which isn't what most users want. I think the key components are to make this work alongside all the apps features/functionalities. Where the intended and actual are still showing "everything" that matches the root/main parent, and then the missing/extra/compliance result filtered down.

Current PR Does

Actual:

router bgp 100
    secret abcd

Intended:

router bgp 100
    secret defg

Compliance:

router bgp 100
    secret abcd

Follows Existing pattern

Actual:

router bgp 100
    neighbor 1.1.1.1 remote-as 200
    secret abcd
    prefix-list JEFF

Intended:

router bgp 100
    neighbor 1.1.1.1 remote-as 200
    secret defg
    prefix-list JEFF

Compliance:

router bgp 100
    secret abcd

@Dav-C I think internally we're thinking of showing both would be good. So either like this screenshot, or potentialy a toggle options between Full|Limited on intended and actual like the YAML|JSON toggle box. Just so the context isn't lost for users.

I had the opportunity to review this new feature and wanted to share some thoughts from an outside perspective:

• It's important that we remain consistent at every step.
• This means we should look at the solution as a whole, not just in terms of a new feature — everything should feel unified.
• From my point of view, HIER-CLI is simply a specific type of configuration. This implies that (a) matching, (b) processing, and (c) reporting behave in a particular way once I decide that my ComplianceRule is of type HIER-CLI.
• If we decide to introduce a header like # hier-cli, we should apply it consistently — across all types. If that's not feasible, perhaps we should reconsider whether the header is needed at all, especially if we can achieve the same clarity by introducing a new, dedicated type like "hier-cli".
• There’s no real need to include more "intended config" for a rule than what’s being matched and reported. Here’s why:
• We already follow a clear pattern — we match a section of the config and report that specific part. We don’t show the entire config above the matched snippet. Even when we have the full config available, we still only focus on the relevant fragment.
• Introducing names like "Filtered configuration compliance" or "Advanced CLI Compliance" might sound overly complex or too heavy. Couldn’t we simply stick with the term HIER-CLI, which clearly conveys the context — i.e. hierarchical configs with a hierarchical processing engine?